Warum spielt TDD in sicherheitsrelevanten Produkten kaum eine Rolle?

Obwohl Test Driven Development viele Vorteile verspricht, hat es sich bis heute nicht umfassend in der Industrie durchgesetzt. Dies gilt insbesondere für sicherheitsrelevante Produkte. Der Vortrag analysiert industrieübergreifende Gründe dafür und stellt eine attraktive Alternative vor.

Die Alternative basiert auf folgenden Forderungen in sicherheitsrelevanten Produkten: Vorgehensmodelle wie ASPICE in der Automobilindustrie forderndas Definieren von Verification Criteria unmittelbar bei der Erstellung von Requirements.

In sicherheitsrelevanten Luftfahrtprojekten fordert der Software Standard RTCA DO178 ein detailliertes Review aller Requirements. Ein wesenticher Punkt dieses Reviews ist die Feststellung der Verifzierbarkeit des jeweiligen Requirements. Ähnliches Reviews werden auch für die sicherheitsrelevante Entwicklung in der Automobilindustrie (ISO26262), der Industrieautomatisierung (IEC61508) sowie der Bahnindustrie (EN50128) gefordert.

Der Beitrag definiert zunächst TDD und stellt in Kurzform die wesentlichen Eigenschaften undVorteile der Methode vor. In einem umfangreicheren Teil werden dann die Herausforderungen von TDD diskutiert, die in der Praxis auftauchen:

• Schwierigkeiten bei der Anwendbarkeit von TDD auf System- und Integrationstests?
• Fehler die früher beim Codieren gemacht wurden, werden jetzt im Testcode gemacht, daherkeine Verkürzung von Entwicklungszeiten
• TDD "verführt" dazu die systematische Dokumentation von Requirements, Architektur und Traceability zu vernachlässigen. Das führt zu folgenden signifikaten Wissenslücken

• * …was genau sind Kundenanforderungen sind.
• * …für welchen Zweck die Software entwickelt wird.
• * …welches Problem mit der Software gelöst werden soll.

Im dritten Vortragsteil werden dann Praxiserfahrungen mit Reviews von System- und Software Requirements in sicherheitsrelevanten Projekten vorgestellt.

Vorgehensweise:

• Durchführung von solchen Reviews (Checkliste, Ebene von Requirements, Traceability Strategie)

Vorteile:

• (Sehr) frühe Klärung von funktionale Unklarheiten, ohne den Aufwand schon einen Test ausformulieren zu müssen
• Sehr schnelle Erkennung von offenen Punkten
• Wichtige Stakeholder können zur Lösung der Probleme beitragen, da kein Know-How von Testskriptsprachen etc. notwendig ist.
• Zeitliche Entkopplung von komplexen Problemen wie der Aufbau einer Testautomatisierung und der Festlegung von Funktionalitäten

Der Vortrag schließt ab mit industrieübergreifenden Erkenntnissen aus sicherheitsrelevanten Projekten die das Augenmerk weiter in Richtung der Richtigkeit von Requirements verschieben:

• Die Meisten Fehler in Softwareprodukten haben Ihre Ursache in einer falschen, unvollständigen, inkonsistenten Spezifikationen (Beispiel: Fahrzeugtest im Auto: Der Anteil von Spezifikationsfehlern ist so hoch, dass die Wirtschaftlichkeit in Frage steht)
• Der Unittests (Der Test bei dem TDD seine Stärke hat), findet praktisch keine/kaum funktionale Fehler
• In der Luftfahrt legt die neue Version der Sicherheitsnorm eindeutig fest, dass es keinen System- Integrations- oder Unittest mehr geben darf, der nicht eindeutig von einem Requirement abgleitet werden kann.
• In der Automobilindustrie gibt es Bestrebungen zukünftig deutlich mehr Aufwand in die Simulation von Systemen zu investieren um Spezifikationsfehler früher zu finden. Das V-Modell wird in Frage gestellt.

zurück zum Programm